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DETAB-X  AND  THE  WORIi)  OF  BAKKIMS 


Solomon  L.  Pollack* 

The  BAND  Corporation,  Santa  Monica,  California 

Jim  Hammond's  talk  has  described  vhat  decision  tables  are.  I 
would  like  to  tell  you  about  a  specific  decision-table  language, 

DEXAB-X  (Decision  Tables,  Ebqperlmental),  an  experimental  language  that 
combines  COBOL-61  aiid  decision- tables .  The  CQDASYL  Systems  Group  has 
designated  DETAB-X  as  an  experimental  lang\iage  In  order  to  emphasize 
that  It  Is  available  on  a  test  basis  to  those  in  the  business  data 
processing  or  scientific  field  who  are  willing  to  experiment  with  It. 
Hopefully,  users  of  the  language  will  provide  feedback  concerning  Its 
merits  and  defects  to  the  CQDASYL  Systems  Group. 

As  a  framework  for  describing  DETAB-X,  let  us  consider  the  three 
major  steps  (shown  In  Slide  l)  that  result  In  a  cooputer  program. 

First,  system  analysts  develop  the  source  program,  which  describes  the 
data  In  their  system,  preparatory  operations  the  data  must  undergo, 
and  the  movement  of  data  through  the  system.  Then  there  Is  the  trans¬ 
lator,  which  converts  the  source  program  to  a  set  of  conputer  Instruc¬ 
tions  called  an  object  program;  In  turn,  the  object  program  Is 
processed  by  the  computer  to  update  files  and  produce  required  reports. 

Slide  2  gives  a  more  detailed  breakdown  of  these  elements.  Here 
we  see  that  the  source  program  consists  of  two  major  parts:  the 

*Any  views  e^qpressed  In  this  paper  sure  those  of  the  author.  They 
should  not  be  Interpreted  as  reflecting  the  views  of  Ihe  RAND  Corporatl(m 
or  the  official  opinion  or  policy  of  any  of  Its  governmental  or  private 
research  sponsors.  Papers  are  reproduced  by  The  RAND  Corporation  as 
a  courtesy  to  members  of  Its  staff. 

This  paper  was  prepared  for  presentation  at  the  l^th  Annual  Con¬ 
ference  of  the  NAtlonal  Association  of  Mutual  Savings  Banks,  Fobruazy  14, 
1963,  at  Boston,  Massachusetts. 
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buslness-orlented  problem  description  and  the  procedures  description. 

The  former  describes  vhat  needs  to  be  done  in  the  business  systan;  the 
latter  describes  hov  the  data  processing  is  to  be  accon^lished.  At 
present,  all  languages,  including  DETAB-X,  intermix  the  what  and  how 
of  data  processing.  It  is  the  System  Group's  hope  that  DETAB-X  will 
lead  to  a  langviage  that  will  enable  the  systan  designer  to  describe 
his  application  separately  from  his  procedures.  Then,  if  a  change 
occurs,  the  system  designer  can  implement  it  by  changing  the  problem 
description,  without  having  to  rewrite  the  entire  computer  source 
program. 

For  the  remainder  of  this  talk,  we  will  focus  our  discussion  of 
DETT.  3-X  on  its  use  for  business-oriented  problan  description.  As  a 
prelule,  it  will  be  useful  to  bear  in  mind  the  desirable  features  for 
a  problem-analysis  technique  (see  Slide  3). 

Any  such  technique  must  first  provide  an  orderly  method  of  docu¬ 
mentation.  People  who  have  been  responsible  for  computer  programs 
know  how  devastating  it  can  be  when  a  programmer  ^o  has  done  little 
or  no  documentation  of  his  programs  leaves  the  organization.  A  good 
technique  will  make  it  relatively  simple  to  document  a  Job.  DETAB-X 
can  serve  this  role  in  business  data  processing. 

A  problem-analysis  technique  that  is  Independent  of  the  processing 
method  enables  the  statement  of  the  problem  to  retain  its  usefulness 
even  if  the  processing  method  changes  later  on.  Too  often,  in  the 
past,  the  entire  application  had  to  be  restated  when  one  ccmputer 
replaced  emother,  only  because  the  processing  method  was  interwoven  with 
the  statements  of  what  needed  to  be  done. 
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When  an  analysis  technique  provides  the  system  designer  with  the 
flexibility  to  change  portions  of  his  analysis,  he  has  greater  free¬ 
dom  of  action  in  documenting  the  application.  For  example,  if  the 
analysis  technique  does  not  imply  that  actions  must  be  performed  in  the 
sequence  in  which  they  are  written,  the  designer  is  free  to  move  from 
application  to  application,  documenting  as  he  goes  along.  He  can  then 
later  determine  the  order  of  processing  based  on  parameters  he  selects. 

In  any  banking  system,  sets  of  actions  occur  as  a  result  of  a 
combination  of  many  conditions;  consequently,  it  is  highly  desirable 
to  have  formats  that  help  the  analyst  visualize  the  resultant  complex 
relationships.  As  we  shall  show  later,  the  decision- table  format  can 
pro\  extremely  useful  in  this  regard. 

The  failure  to  consider  one  or  more  conditions  is  a  continual 
threat  to  those  responsible  for  developing  data  processing  systems. 

An  omission  in  the  problem  statement  may  not  be  discovered  until  the 
system  has  been  operating  many  months.  Consider  a  savings-ewcount 
systmn  being  processed  on  a  computer.  A  series  of  actions  have  been 
specified  for  each  type  of  transaction  designated  by  the  system  de¬ 
signers;  but  —  people  being  what  they  are  --  it  is  possible  that  one 
kind  of  transaction  was  not  provided  for.  The  bank  manager  would  cez*- 
tainly  want  the  computer  system  to  reject  the  first  one  of  those 
transactions  to  enter  the  system,  so  that  he  could  take  steps  to  process 
them  properly.  Decision- table  techniques  make  it  relatively  easy  to 
review  any  system  description  for  amissions  and  inconsistencies. 

DETAfi-X  prescribes  C0B01j-61  as  the  language  to  be  used  in  a 
decision-table  structure.  This  is  to  enable  those  who  intend  to  process 


their  applications  on  computers  to  take  advantage  of  the  many  COBOL-61 
con5)ilers  (translators)  that  are  currently  becoming  available  from 
the  computer  manufacturers;  however,  DETAB-X  can  also  be  useful  for 
banking  systems  that  are  not  tied  in  with  conputers . 

To  Illustrate  the  features  of  DBTAB-X,  we  first  descriue  a  bank¬ 
ing  function  in  the  conventional  form  (see  Slide  4)  and  then  describe 
that  same  function  in  decision- table  form  (see  Slide  3)< 

Note  that  the  narrative  form  (see  Slide  4)  is  serial  in  nature. 
The  comparisons  and  the  actions  based  on  those  ccm^axlsons  must  occur 
in  the  order  in  which  they  are  specified.  Note  also  that  this  form 
does  not  lend  Itself  easily  to  analysis  or  to  checks  for  coiq;>leteness 
and  accuracy.  It  is  difficult  to  tell  whether  all  the  appropriate 
comparisons  on  transaction-type,  number,  ana  transaction-code  have 
been  made.  Also,  if  a  comparison  is  made  against  several  values,  it 
is  very  difficult  to  spot  wrong  values,  because  corresponding  values 
appear  in  different  paragre^hs,  some  distance  from  each  other. 

Let  us  turn  to  Slide  ^  which  shows  these  same  rules  in  decision- 
table  form.  Notice  that  when  the  conditions  are  laid  out  in  tabular 
foim,  the  system  designer  Is  better  able  to  determine  if  he  has  con¬ 
sidered  all  the  possible  conblnatlons  of  conditions  that  might  occur. 
He  knows,  for  example,  that  if  there  are  two  conditions  that  can  oe 
satisfied  or  not  satisfied  (lines  land  2  of  Slide  and  one  condi¬ 
tion  that  can  eissume  any  one  of  four  values  (line  3  of  Slide  then 
a  total  of  22  X  4  »  l6  rules  can  be  formed. 

Rule  1  is  equivalent  to  4  rules  by  virtue  of  the  dash  on  line  3* 
Hence,  Rules  1-^  represent  a  totaJ.  of  8  rules.  Since  l6  rules  are 
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posslble,  8  rules  are  missing.  In  DETAB-X,  we  represent  the  missing 
rules  by  an  ElgE-Decision-Rule.  It  is  the  rightmost  rule  in  SlUe 

DETEAB-X  differs  from  other  languages  that  describe  decision 
rules  in  that  the  rules  specified  in  the  decision  table  do  not  have 
to  be  executed  In  the  order  they  have  been  written  In;  that  Is,  rule  1 
does  not  have  to  be  executed  first.  This  gives  the  compiler  freedom 
to  determine  the  order  of  rule  execution  based  on  some  parameter  such 
as  frequency  of  occurrence.  For  exanqple,  if  a  particular  rule  is 
executed  90  percent  of  the  time  and  the  rest  only  10  percent.  It  Is 
certainly  more  efficient  to  have  that  90  percent  rule  executed  first. 
The  format  of  DETAB-X  makes  it  easy  to  specify  the  parameter  for  each 
rule  so  that  more  efficient  object  programs  can  be  developed. 

In  Slide  6  ve  have  listed  some  desired  goals  for  future  business 
languages.  It  Is  our  hope  that  DETAB-X  Is  a  step  In  this  direction. 

We  feel  that  DETAB-X  can  help  users  in  documentli^  their  system  In 
that  programs  written  in  DETAB-X  will  provide  Improved  communication 
between  system  designers,  programaers,  emd  functional  specialists. 
DETAB-X  is  also  expected  to  Increase  the  accuracy  and  cooqpleteness  of 
problem  statement  achievable  by  existing  languages .  It  is  available 
to  anyone  willing  to  try  it,  emd  the  Development  Committee  would  e^- 
preclate  receiving  any  information  on  the  merits  and  defects  of  the 
language.*' 


^Criticisms  and  suggestions  concerning  DBIAB-X  should  be  sent  to 
Solomon  Pollack,  Hie  BAND  Corporation,  1700  Main  Street,  Santa  Monica, 
California. 
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